1. Field of the Invention
The present invention relates to computer software, and deals more particularly with a method, system, and computer program product for blending object-oriented programming languages with traditional programming languages such that they can execute and share data in a coordinated and integrated manner.
2. Description of the Related Art
Many modern program development environments include both object-oriented (OO) components and traditional non-object-oriented (non-OO) or procedural programming language constructs. The OO components are often used in the user interface. They may also be the main data objects that describe the business system (e.g. Customer objects, Order objects, and so forth in a customer ordering application). The business logic of the application, however, might not be written using an OO language, but might be written instead in a more traditional procedural programming language. It might even be legacy code that only uses OO objects by introduction of a new graphical user interface (GUI). The OO and procedural constructs might even use two completely different namespaces.
A problem arises when developers need to merge the OO and non-OO technologies in a productive way. When application environments include a mix of OO objects and non-OO programming language constructs, there is typically no efficient way for the business logic written in the non-OO programming language to interface with and manipulate the OO objects without interrupting the flow of the business logic.
The problem of integrating OO and non-OO languages was discussed in xe2x80x9cBridging traditional and object technologies: Creating transitional applicationsxe2x80x9d, A. H. Lindsey and P. R. Hoffman, IBM Systems Journal, Vol. 36, No. 1, (1997), which focuses on rapid application development using visual programming and object-oriented techniques. The section titled xe2x80x9cPart and Object Scripting from within Traditional Languagesxe2x80x9d discusses the need to provide access to visual parts from within non-OO code. The approach described therein is to introduce an xe2x80x9cobject handlexe2x80x9d into the non-OO code namespace, and then to provide addressability to objects in the GUI namespace using instances of object handles to (1) get to parts on the GUI, and (2) get to other OO objects. This approach was intended to enable sending messages to parts or objects, passing arguments, and signaling events that the part or object understood.
The disclosed solution had a number of problems in actual implementation, however. First, it was very complicated, leading to even more difficulties for developers attempting to xe2x80x9cbridge the gapxe2x80x9d between OO and traditional programming. In addition, the object handle concept did not fit well into the non-OO data item concepts, where a number of the concepts used in the OO world (null values, etc.) do not typically exist. Furthermore, the built-in functions described in the disclosed solution required developers to code complicated data conversion techniques in order to pass arguments of the proper type.
There have been other attempts to bridge this gap between OO objects and non-OO languages, but they have proved inadequate. One prior art approach uses visual connections depicted on a GUI to control OO objects. Several graphical composition editors are commercially available to support this type of programming, which may function adequately for very simple scenarios. However, in a real application system this approach quickly becomes a maintenance and performance nightmare. The graphical representation of the OO objects becomes cluttered with visual connections to control the OO objects directly, or to execute OO scripts to control the objects. In addition to being visually cumbersome, these visual connections cannot be driven effectively from within the business logic because there is no non-OO construct to fire the GUI visual events in amongst the other non-OO code.
Another prior art approach is the xe2x80x9cPerformRequestxe2x80x9d support which is provided in the IBM VisualAge(copyright) Generator (hereinafter, xe2x80x9cVGxe2x80x9d) product. (VisualAge is a registered trademark of IBM.) This PerformRequest technique allows the VG non-OO code to set up an object to manipulate the OO objects after a business logic component has completed execution. This allows some level of mixing OO objects and non-OO programming languages, but it is inefficient and unnatural because the interaction with the OO objects does not take place during the natural flow of the business logic. Instead, the non-OO business logic must come to the end of the currently-executing component (where a component is analogous to a subroutine or function), and then control can be given over to the OO context where results of the business logic may be reflected in the objects and on the GUI. (Note: the term xe2x80x9ccontextxe2x80x9dis used herein in a general sense and not as a specific computer science term. For example, xe2x80x9cOO worldxe2x80x9d, xe2x80x9cOO environmentxe2x80x9d, and xe2x80x9cOO contextxe2x80x9d are all intended to be synonymous.) The data used by the two parts of the system (i.e. the GUI part and the business logic part) is not synchronized, and there is therefore no way to manipulate an OO object in one business logic statement and then immediately use the results of that OO object change in the next business logic statement.
There are many situations in which the business logic code needs to directly interact with OO methods as the business logic executes, rather than awaiting completion of the invoked business logic, such that the two parts of the system can execute in an integrated manner. Prior art systems do not provide this type of integration. To illustrate the problem, suppose the business logic performs analysis or error checking of data values which an application user enters into the fields of a user interface panel. Further suppose that this analysis code is designed to display an error message window, at run-time, upon detecting a problem with any of the input data values. Preferably, each detected error would be displayed as it is detected. If the procedural business logic construct has no facility for returning control to the GUI context until all of the business logic corresponding to the invoked GUI event has completed, the error message window will not be displayed at the most appropriate time (and any related OO logic will not execute in-line, before other business logic data processing occurs). This delay between detecting an error and presenting it on the GUI, while control is forced to remain in the business logic being executed until that code completely finishes, leads to an unnatural, inefficient reflection of the results of the business logic""s processing on the user interface.
In many application scenarios this non-integrated execution presents an especially undesirable approach. Suppose, in this same example, that the application allows the user to enter values of several fields into the GUI before invoking the business logic which analyzes each field value. (This approach may be useful, for example, when the value of one field dictates the allowable values of another field.) It may therefore happen that multiple error messages are generated while the business logic executes. Because the non-integrated code does not present error messages upon detection, the developer must typically provide a means for saving each generated message until all the analysis code completes, and a means for then displaying each message in sequence (preferably, in order of the business logic processing). This may be done, for example, by creating a collection or table of error messages as the procedural analysis code executes, and then iteratively processing each saved element of the created structure in the GUI code for display to the user when the analysis code is complete. However, this approach is quite cumbersome and is therefore undesirable.
Many other scenarios can be envisaged where the lack of integration between OO and non-OO parts of a system presents similar difficulties.
In the general case, developers are left with the choice of presenting this type of unnatural, unintegrated interaction to their application users, or of designing the procedural code to avoid this situation (e.g. by attempting to break the business logic into smaller components, enabling control to return to the GUI more often). The latter technique is no more desirable than the former, as it makes the coding task more difficult and yields an artificial application design which is adapted to the limitations of the execution environment, rather than toward the problem being solved by a particular application.
Accordingly, what is needed is a technique for blending object-oriented methods and procedural language code components such that they execute and share data in a seamless, integrated manner, where control efficiently passes from one to the other and avoids the problems of prior art systems. This seamless operation should be provided even though the methods and procedural components may be using different namespaces.
An object of the present invention is to provide a technique for blending object-oriented methods and procedural language code components such that they execute in a seamless, integrated manner.
Another object of the present invention is to provide this technique whereby control efficiently passes back and forth between object-oriented code execution and procedural language code execution.
Still another object of the present invention is to provide a technique for sharing data values among OO methods and procedural components which are executing in different namespaces.
A further object of the present invention is to provide a technique for synchronously invoking object-oriented methods during execution of a procedural code component, such that processing control passes seamlessly from a procedural code component to an object-oriented method and back again.
Another object of the present invention is to provide this integrated execution technique by supporting a special keyword construct that triggers invocation of a named OO method.
Other objects and advantages of the present invention will be set forth in part in the description and in the drawings which follow and, in part, will be obvious from the description or may be learned by practice of the invention.
To achieve the foregoing objects, and in accordance with the purpose of the invention as broadly described herein, the present invention provides a method, system, and computer program product for seamessly integrating execution of object-oriented methods and procedural language code components. In one aspect, this technique comprises: accessing one or more object-oriented methods written in an object-oriented programming language; accessing one or more procedural components written in a procedural programming language, wherein at least one of the procedural components contains one or more references to selected ones of the object-oriented methods, selecting, by a user of the technique, an event from a graphical user interface, wherein the event is operably associated with a selected one of the procedural components; executing the selected procedural component under control of a procedural run-time engine, responsive to the means for selecting; transferring control from the procedural run-time engine to a particular one of the object-oriented methods upon encountering one of the references in the executing procedural component, wherein the encountered reference identifies the particular one; executing the particular object-oriented method; and returning control to the procedural run-time engine upon completion of the execution of the particular object-oriented method.
The encountered reference preferably further comprises a special keyword to signify the encountered reference and a name of the particular object-oriented method, and the technique preferably further comprises performing a synchronization of data values prior to the transfer of control. The transfer of control, execution of the particular object-oriented method, and return of control preferably operate to provide a synchronous execution of the particular object-oriented method. The technique may further comprise loading data values set by the executing procedural component into sharable storage prior to the transfer of control, and accessing the loaded data values during the execution of the particular object-oriented method.
In another aspect, the technique comprises: executing one or more object-oriented methods written in an object-oriented programming language; executing one or more procedural components written in a procedural programming language; and synchronously executing a selected object-oriented method during execution of a processing path of a selected procedural component. The synchronous execution may further comprise: loading data values into sharable storage during execution of the processing path of the selected procedural component; detecting, within the processing path of the selected procedural component, a keyword-based method invocation of the selected object-oriented method; transferring execution control, upon detecting the keyword-based method invocation, from the processing path of the selected procedural component to the selected object-oriented method; executing the selected object-oriented method, upon the transfer of control; accessing the loaded data values during the execution of the selected object-oriented method; and returning execution control to the processing path of the selected procedural component. Returning execution control may operate in response to encountering an end of execution of the selected object-oriented method.
The present invention will now be described with reference to the following drawings, in which like reference numbers denote the same element throughout.